The only doubt I have here is that the result of getString(null) will be NPE with quite cryptic message "name".
Maybe the message should be a bit more descriptive? Like "Null configuration property name".
This applies to all changes below.

Good catch, updated the message to be more descriptive. Thanks!

For consistency I'd recommend adding here also:
Objects.requireNonNull(defaultValue, "Null default value");

Makes sense, added the null check for defaultValue too.

We need to get consistent about whether or not we do this. We rely on javax.annotation.Nullable annotation, the assumption that params and returns are non-null unless otherwise specified, leveraging the net.ltgt.nullaway error prone plugin to validate at build time. Of course, at runtime there is no guarantee that callers adhere to these annotations, and so we have code like this which checks for null despite the params being non-null according to the annotations.

We need to be consistent about:

• When and why do we add additional null checks
• Where do we do this (i.e. in interface default methods or in the actual implementation)
• What is the behavior when the null annotation is violated (throw or noop)

Let's hold off here until we get some repo level guidance on this. ConfigProperties, the env var / sys property analog of DeclarativeConfigProperties, has the exact same method and does not do this null check.

Created #8173 to track.